As may be appreciated, a content management server (CMS) is employed by an enterprise or organization to build, deploy, and maintain a content-rich web site such as that which may be accessible by way of the Internet or another network. Such a CMS streamlines the web publishing process, thereby reducing costly site maintenance and empowering the enterprise or organization to manage its own content. An example of such a CMS is provided by the MICROSOFT Content Management Server application, as developed and marketed by MICROSOFT Corporation of Redmond, Wash., USA.
Thus, a CMS is employed to deploy an Internet, intranet, or extranet web site, and provides tools necessary to build and deploy the core infrastructure of a web site, including site structure, presentation templates, site design, application integration, and security. In addition, once a site has been deployed, managers and content authors can use CMS tools to create, publish, and manage their own content.
Typically, a CMS provides content managers, authors, and the like with tools that enable such personnel to create and publish rich, personalized content directly to a web site. A role-based distributed publishing model is typically employed, where such model incorporates an approval workflow with multiple levels, automatic content scheduling and archiving, and content indexing. Developers can create centrally-managed page templates and publishing processes that ensure consistency across the site, thus ensuring adherence to organizational publishing standards and branding without diminishing the flexibility of the publishing environment.
As may be appreciated, in response to each request for a page, the CMS may serve the page dynamically by freshly generating the page based on information already present in an associated data base and/or information available from other sources (i.e., ‘from scratch’), and then serving the generated page in response to the request therefor. However, and as should also be appreciated, generating each page from scratch is relatively expensive in terms of execution time, processor availability, network bandwidth, and the like.
Accordingly, and as is known, in response to a first request for a page, the CMS may generate the page from scratch, serve such generated page, and also cache such generated page and/or portions thereof, and in response to a second request for a page, the CMS may merely retrieve the cached page and/or portions thereof and serve same.
However, and significantly, it is to be appreciated that the same page may contain subtle or even non-subtle variations as between two requests therefor. For example, in a first variation for a first user or group of users, the page may have a first header, and in a second variation for a second user or group of users, the page may have a second header. Of course, variations may occur in many other page features, including the body of the page, the footer of the page, particular sections to appear in the page, etc. The reasons for the variations are many, but examples of such reasons include the user having a particular browser, the user being in a particular geographic location, the request being made at a particular time, and most significantly with regard to the present invention, the user having particular user rights with regard to viewing the page, among others.
Thus, caching a particular page may actually require caching each of the multiple variations of the page and/or portions thereof. Note, though, that in the course of caching every one of the multiple variations of the page and/or portions thereof, it should not be the case that such caching is performed with too fine a granularity. That is, if a page as cached is really unique to only one or only a few users, then the CMS will have to generate and cache the page an overly large number of times, especially if there are many requesting users. Of course, such over-generating and over-caching defeats the purpose of having the cache in the first place.
Correspondingly, it should not be the case that such caching is performed with too course a granularity. That is, if a page as cached is common to many users, then the page as generated and cached by the CMS must be amenable to all of such users. However, such an amenable page is likely too overbroad or generalized to be of much use to any particular user.
A need exists, then, for a method and mechanism for caching a page based on an appropriate granularity. In particular, a need exists for such a method and mechanism that caches based on one or more attributes by which the page may vary. Even more particularly, a need exists for such a method and mechanism that caches based on the rights a user has with regard to a page, whereby such rights are exemplified by membership of the user in one or more user groups.